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Abstract 

It is possible to create seamless digital maps from Survey of India topographic sheets, by separately 
georeferencing each N-S strip of sheets which share the same projection to a sepárate metric grid, back- 
projecting from the sepárate metric grids to geographic coordinates on the Everest 1956 elipsoid, and then 
joining the strips. This method can also combine maps from different scales. The procedure is explained 
in detail using Arc/Info terminology, and outlined for ILWIS 2.1 for Windows. 
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Introduction 

In his informative arricie ‘Abandon Polyconic Projection’ [1], Dr N K Agrawal makes a very persuasive 
case that Survey of India (SOI) should produce topographic maps on a common metric grid. However, he 
States that since each sheet is projected individually on its own central meridian, “we can not have seamless 
data in a rectangular coordínate system”, and further, “It will not be possible to compile a 1:250,000 sheet 
from sixteen 1:50,000 sheets using digital mapping procedures”. On the contrary, digital techniques can in 
fact be used to create seamless data, both for adjacent sheets of the same scale and for larger-scale sheets 
within a smaller-scale sheet, albeit with more difficulty than if Dr Agrawal's suggestions were adopted. In 
this arricie I outline a procedure for creating seamless digital coverages from adjacent SOI topographic 
maps, even of different scales. The procedure is explained in Arc/Info terminology because of this GIS’s 
wide use, but users of other systems with the same facilities for georeferencing should have little difficulty 
adapting the procedure for their use. In fact procedures are easier in ILWIS 2.1 for Windows, as outlined 
later. Although the procedure is a bit tedious, it illustrates very well the power of a trae GIS, that is, one 
that is able to georeference in any defined coordínate and projection system, and convert among systems. 
The basic idea is as follows; I then explain each step in more detail: 

1 . A sepárate grid coordínate system is created for each N-S strip of map sheets in a single map 
series (i.e., scale), each using its own central meridian but otherwise the same projection parameters; 

2. Comer tics corresponding to the Lat/Long graticule for each strip are projected into that strip’s grid 
coordinates; 

3. Maps from each strip are registered to the digitizer using the córner tics from that strip's grid 
coordinates; 

4. Coverages from each strip are separately digitized in that strip’s grid coordinates; 

5. Coverages from each strip are separately projected back to geographic coordinates; 

6. Coverages from adjacent strips are merged in geographic coordinates to create a seamless, single 
coverage. 
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At this point, coverages can be used directly in geographic coordinates (as is preferred by ArcView, for 


example), or projected into any defined grid system, including Dr. Agrawal's proposed Andhra Pradesh 
Grid [2], I now explain each step in more detail. 

(1) Create a sepárate grid coordínate system for each N-S strip 

For each map series (1:250,000 [l°xl°], 1:50,000 [15’xl5’], and 1:25,000 [7’30”x7’30”]) in the digitizing 
project, organize them in N-S strips sharing the same limiting meridians. For each strip, create two 
Arc/Info projection files, one from geographic to grid, and inversely. Ñame the files for the map series and 
the central meridian. Flere is an example file named ‘250773p.prj' meaning ‘1:2,50,000, 77°30\ to 
projected', and its inverse, named ‘250773g.prj’, with the same meaning, except suffix ‘g’ meaning ‘to 
geographic’. 


Projection File ‘250773p.prj’ 
geographic to projected 

Projection File ‘250773g.prj’ 
projected to geographic 

input 

input 

projection geographic 

projection polyconic 

units dd 

spheroid everestl956 

spheroid everestl956 

units meters 

parameters 

parameters 

output 

77 30 00 

projection polyconic 

00 00 00 

spheroid everestl956 

0.0 

units meters 

-1000000 

parameters 

output 

77 30 00 

projection geographic 

00 00 00 

units dd 

0.0 

spheroid everestl956 

-1000000 

parameters 

end 

end 


The key points here are: (1) the central meridian in DD MM SS, which is different for each N-S strip, 

(2) an optional false origin for Y, so that grid N coordinates will not be numerically too large; (3) the 
spheroid. Now each N-S strip at each scale has its own, sepárate, grid coordinate system with (X,Y) origin 
at the central meridian and approximately 9 ° N (since 90° = 10,000km, each -l,000,000m of false northing 
brings the origin north about 9 o ). If the study zone is further north or south, you can adjust the false 
northing accordingly. 
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For the N-S strip to the E of this one, the two files would be named ‘250783p.prj' and 
‘250783g.prj’, with the only difference from the above example being the central meridian, which would be 
‘78 30 00' instead of '77 30 00'. 

This example is for maps using the Everest 1956 spheroid; for older maps, the Everest 1930 
spheroid must be used. Arc/Info can perform a datum transform between these, as explained in the 
documentation of the ‘project' command. 

(2) Create a geographic grid and projected tics 

For each N-S strip, create a new fine coverage, again named for the map series and central meridian, e.g. 
‘250773g\ Using command ‘generate’ (which allows entry of coordinates from the keyboard or a text 
file), directly enter the bounding meridians and intermedíate parallels, in geographic coordinates. For 
example, for a project covering two adjacent N-S sheets, the fines would be the bounding box (77,12), 
(78,12), (78,14), (77,14), (77,12) and the cross parallel (77,13), (78,13). Don't use the digitizer, rather, 
enter exact coordinates from the keyboard. Create polygon toplogy using command ‘clean' and, if you 
wish, label the polygons with the map sheet ñames; this can itself be a useful coverage. Do the same for 
adjacent N-S strips. For example, the strip to the E of the one already created would have the bounding 
box (78,12), (79,12), (79,14), (78,14), (78,12) and the cross parallel (78,13), (79,13). You now have exact 
geographic limits for each map sheet, organized by N-S strips. 

Each polygon coverage should already have four georegistration points, known in Arc/Info as ‘tics’, 
i.e. the strip corners. Add tics (again, using the keyboard and ‘generate’) at the intermedíate corners, so 
that each Lat/Long intersection has its own tic. Make a note of the correspondence between tic numbers 
and geographic coordinates. In the example, tics would have to be added at (77,13) and (78,13) in the 
western N-S strip, and at (78,13) and (79,13) in the eastern N-S strip. 

Now, project each N-S strip of map sheet limits into its own metric grid, using the ‘to projection' 
projection file; in the example above: project cover 250773g 250773p 250773p.prj. The tics will also be 
projected. Viewing the projected coverage, you will see X=0m on the central meridian, mínimum 
(negative) X at the lower left córner (the widest parallel), e.g. -54,45lm, máximum (positive) X at the 
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lower right córner, e.g. 54,45 lm. Y valúes will be positive, and cover a range of about 110,856m per 
1:250,000 sheet (the exact range depends slightly on latitude). 

In the example above, the corners of the W strip would be: (-54444.09m E, 327033.86m N), 
(54444.09m E, 327033.86m N), (54009.79m E, 548285.30m N), (-54009.79m E, 548285.30m N). Note 
that the extreme X valúes are the same with changed sign; this is because the central meridian is X=0. Also 
note the different widths: going from 12 to 14°N reduces the width of a parallel of I o by [(54444.09 - 
54009.79) x 2) = 868.6m, from a total of (54444.09 x 2) = 108,888.18m at 12°N. These results will of 
course vary with latitude. The corners of the E strip are exactly the same, but in its own coordinate system. 
(3) Register maps to projected tics 

To create a new coverage from a paper map, first create the new (empty) coverage, copying the tics from 
the appropriate N-S strip and map series in the same step. Indícate in the coverage ñame that it is 
projected, e.g. with a ‘p’ suffix.. For example, to create a coverage of roads (prefix ‘r’), you could use 
command createcov r250773p 250773p. Then, register the paper map (command ‘coordínate digitizer’) to 
the digitizer using the córner tics. The RMS error of digitizer registration will be expressed in digitizer 
units, and should be converted to map scale. For example, with a good quality map, a high-resolution 
digitizer, and careful operation, a RMS error of less than 0.005” = 0.127mm is expected. At 1:250,000 this 
is equivalent to 31.75m ground resolution. This is an order of magnitude smaller than the gap between 
adjacent strips at their N end of 417.86m on the ground = 1.67mm on the map sheet, for a 1:250,000 sheet 
based at 12°N. The further North one goes, the worse this problem becomes, as illustrated in Dr. 

Agrawal's [1] Figure 1, which shows an map sheet gap of ~3.2mm, equivalent to 800m (actually, 801.64m) 
on the ground for the N end of a sheet based at 24°N. This shows why it is inadvisable to use an affine 
digitizer transformation directly on the geographic, rather than the projected, coordinates. 

At larger map scales, the gap is smaller in ground meters but very similar on the map sheet. For 
example, on a 1:50,000 map (15’ x 15’) based at 24°N, the gap between adjacent strips at their N end 
(24° 15') is 197.52m on the ground = 3.95mm on the map sheet. 
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(4) Digitize 

The digitizer should now read out directly in meters. Digitize the coverage. Do not digitize the neatlines, 
since on SOI toposheets they are not correctly drawn (see below). A well-defined point should be digitized 
to 0.01” ~ 0.25mm = 62.5m ground resolution at 1:250,000; this is the acceptable printing error of the 
original map. 

(5) Project coverages to geographic coordinates 

This is the reverse of step (2). Indicate in the unprojected coverage ñame that it is in geographic 
coordinates, e.g. with a ‘g’ suffix.. Use the inverse ‘to geographic' projection file created in step (1), e.g. 
project cover r250773p r250773g 250773g.prj. Viewing the unprojected coverage, you will see 
geographic coordinates; in particular, the tics at the map corners will again be exact Lat/Long. Reversing 
the example of step (2), we can see that the geographic point (78°E, 14°N) is equivalent to grid point 
(54009.79m E, 548285.30m N) in the grid system centered at 77°30\ as well as to grid point 
(-54009.79m E, 548285.30m N) in the grid system centered at 78°30\ If this, or any other point on the 
boundary between the two strips were digitized in both grid systems, it back-projects to the same 
geographic coordinate, as required, subject of course to human error during digitizing and to digitizer 
resolution. 

(6) Join coverages into one seamless map 

Once you have done this for adjacent N-S strips, all coverages will be in a common coordinate system, i.e. 
uprojected geographic. Combine them with standard map joining procedures (command ‘mapjoin' for 
polygons, ‘append' for lines, using a snap tolerance of 0.01” ~ 0.25mm converted to map scale). However, 
there is a slight complication. As explained by Dr Agrawal [1], SOI toposheets in fact are printed with 
straight rather than curved neatlines. Thus, features (e.g. a road) will not exactly match at the printed 
neatlines, although the sheet córner points will match precisely. This is solved by adjusting the snap 
tolerance during the map joining procedure to a valué a bit greater than the error, as just explained. It is 
also possible, but tedious, to manually correct undershoots or overshoots, e.g. using command ‘edgematch'. 
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The error due to drawing straight rather than curved parallels is a máximum at the central meridian 
of each sheet, and is greater than digitizer error at all scales, e.g. at 12°N it is 49.40m for 1:250,000 scale 
maps. This error increases as one goes North; e.g. at 24°N it is 90.27m. At the top of a sheet a bit too 
much is shown (i.e., the neatline is above its corred position), at the bottom a bit too little. Two adjacent 
sheets in a N-S strip almost exactly match, even though the neatline is not drawn correctly on either sheet, 
therefore map joining in the N-S direction (across parallels) should be easy. 

The error due to drawing straight rather than curved bounding meridians is much smaller, because 
the complex curve of the polyconic projection is very cióse to a straight line. For example, at 12°30'N, 
78°E, the difference between the true projected point and the point on the straight line from (12°N, 78°E) to 
(13°N, 78°E) is only (2.055m, 1.305m) in (X, Y) at 1:250,000 map scale, much lower than digitizer error. 
The straight line is a very slight overshoot on both sides. The error becomes slightly smaller in X and 
slightly larger in Y as one goes North. So, there is no problem with map joining in this direction either. 

If you would like neatlines surrounding the study area, add them at this stage, as in step (2). If you 
would like an overprinted geographic graticule, use the coverage created in step (2); the sepárate N-S strips 
may be merged into a common coverage. 

Finally, the coverage may be projected into any defined coordinate system, e.g. UTM, using an 
appropriate projection file. 

Variations 

Other GIS packages may handle this problem a bit differently from Arc/Info, but should be able to achieve 
the same goal. For example, procedures are much simpler in ILWIS 2.1 for Windows [3], produced by my 
institute. ILWIS is able to register a projected map to the digitizer directly in geographic coordinates, if the 
projection is known (see Help topic ‘Map Referencing (1)’). In effect, the ILWIS programmers have 
combined projection into the digitizer referencing procedure. Then the coverages are from the first 
produced in unprojected geographic coordinates and may be combined (using commands ‘glueseg' or 
‘gluepnt') without problem. The ILWIS command ‘TransfCrd’ is also a useful calculator for transforming 
coordinates between projection systems and with unprojected geographic coordinates, and in fact I used it 
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to make all the calculations in this paper. In ILWIS, one must create a Coordínate System file, with the 
appropriate parameters; this is simpler than in Arc/Info, because the parameters are requested in a Windows 
dialog box with on-line Help. 

Discussion 

The procedure explained in the paper is not worth the trouble unless one has good quality maps, a high- 
resolution digitizer, and careful operation. Any problem with these will make the registration error on the 
digitizer greater than the error due to using unprojected coordinates. If the RMS error of map registration is 
greater than about 0.05” (vs. the ideal 0.005” or less), all benefit is lost. 

It would certainly be ideal if SOI would create seamless digital coverages on a conformal projection 
and make them available to the public at cost. However, considering SOI's track record in this matter, the 
Indian GIS community can not afford to hold its collective breath that long. Meanwhile many GIS 
projects, especially in natural resource evaluation and management, must by necessity use SOI toposheets 
as the most reliable map georeference. The procedure outlined in this article should allow any study area, 
no matter how large, to share a seamless, correct digital map in geographic coordinates, and moderately 
wide areas (e.g. the size of a UTM zone, 6°) to share a seamless, correct digital map in a common grid. 

PostScript: geo-referencing maps with no coordinates 

Often one is presented with a thematic map supposedly drawn on a SOI base, but with no coordinates or 
geographic grid. To incorpórate such a map in a GIS, the correct procedure is: 

1. Prepare a projected grid covering the area, as explained in this article. 

2. Identify common control points on the thematic map and SOI toposheets. Examples are road junctions, 
railways, and sharp corners of political boundaries. 

3. Register the SOI toposheet to the digitizer using córner tics, as explained in this article, and digitize a 
point coverage of these points from the SOI toposheets, in grid coordinates. 

4. List the points to a text file, e.g. with ‘ungenerate’. 

5. Create a coverage for the thematic map, copying the tics from the projected grid. 
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6. Add the control points as tics from the keyboard or a text file, using ‘generate'. They will be in 
projected meters. 

7. Register the map to the digitizer using the projected control point tics (not the corners, since you don't 
have these on the thematic map). 

8. Digitize the thematic coverage, in projected meters. 

9. Unproject the thematic coverage to geographic coordinates. 

Good luck! And write up your experience for this magazine. 
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Figure 1 

Unprojected Geographic Coordinates 



Figure 2 

Projected Metric Coordinates 
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